Technical Requirements 

for VentureVortex.com v2.0 Establish 



prepared for 

VentureVortex 

October 17, 2000 



Executive Summary 

The Technical Requirements are a technical perspective of the general needs for the success of the 
project These should be analyzed alongside the business and functional requirements and as such are 
not granular recommendations but higher-level considerations. 

These specifications are for the current project as defined in the Statement of Work. All quantities within 
this document were derived from business requirements and functional limitations of the components 
assumed to play a role in the project. All quantities are set at the limitation of the bottleneck of a 
process, not the average capabilities of the systems involved in a process. Therefore the quantities 
described within are not maximum or minimum characteristics of every system in the project but of one 
particular system for each process. 

This document and all information contained within therefore are not meant to denote restrictions for 
future phases of the site. Whereas the project will be architect to allow for future growth this document 
describes the limitations of the current project. 

Within this document the word 'user' refers to any public user of the site, i.e. any user other than 
administrators of the site. 

Areas of Consideration: 



• Concurrent Usage 

• Performance 

• Capacity 

• Usability 

• Scalability 

• Availability 
• ' Security 

• Compatibility 

• Integration 

• Back-up & Recovery 

• Disaster Recovery 



Concurrent Usage 

Concurrent usage is the number of users that are expected to perform an action on the system 
simultaneously. All portions of the application must support this number of concurrent users. This also is 
an assessment of the needs of the site at this time and for this phase. Further growth would require a 
reassessment of the system. 

We currently anticipate that up to 2,000 concurrent users will be able to use the site at this time. This 
includes usage of eRooms, the Business Plan Rating System and the Dashboard views. 



Performance 

Performance is defined as the time processes take to complete. Normally this is measured by the time a 
typical user would experience and not the actual time of the system. Note that these times assume that 
the connection and systems outside the realm of influence of the project are normal and reliable. 
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Capacity 

Capacity is the amount of user information and other data that the system can store. This only includes 
information pertaining to the system and not historical data such as web server log files or data 
warehouses. 

The system should be able to support up to 50,000 users. Up to 5,000 eRooms should be supported and 
each eRoom should be able to store 20 megabytes of information (no quota system is available in 
eRoom). 



Usability 

Usability is defined as the user's ability to access the information and functionality provided by the 
system. User interface can range from simple anchors to complex navigational structures to interactive 
tools. While usability is handled by user interface engineers and visual designers, technical engineers 
normally require specific elements to be included. 

The site should incorporate a navigational system that allows users to access all facets of functionality. 
Users should be able to access all applications whether in Coldfusion, eRoom or any other system. The 
Dashboard views will provide summaries of information contained within these systems as well as 
dynamic content 



Scalability 

Scalability is defined as the ability for the system to grow to meet future user needs. There is normally a 
limit at which the current system will need to be upgraded to a more robust infrastructure. However up 
to this limit the system should be able to scale using additional hardware or software packages. 

All Coldfusion applications will be coded to be fully compatible with clustering and load-balancing as 
provided by Coldfusion. AH databases will reside in an RDBMS such as Microsoft SQL Server that is 
expandable and a proven record of high-capacity functionality. All third-party packages such as eRooms 
will support scalability on a single server. 



Ava liability 

Availability is the percentage of total time that the site should be fully available. While 100% availability is 
optimum in real-world conditions this is impractical. Also at some point the law of diminishing returns 
applies and causes improvements in availability to become more costly than the gains. 

The site should be available 99.9% of the time. This interpolates to the following matrix: 
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Availability 



Downtime Per Year 



99% 



87 hours, 36 minutes 
43 hours, 48 minutes 
8 hours 30 minutes 
4 hours, 23 minutes 



99.5% 



99.9% 



99.95% 



99.99% 



53 minutes 



99.999% 



5 minutes 



This figure will be achieved by a plan submitted by the hosting provider. 



Redundancy 

Redundancy is defined as having multiple instances of a component available at all times so that if One 
component fails, other components) will still perform the functionality. Redundancy can be achieved 
from both a hardware and software level. Redundancy is normally a very expensive attribute of a project 
because it requires not only multiple instances of components but multiple upgrades and maintanence. 

The site will not have any custom redundancy. All redundancy will be handled by the hosting provider. 



Security 

Security relates not only to access to the system itself but to the data stored within it. Security can be 
achieved through both technology and work processes. Technology such as transmission encryption, 
passwords, public key infrastructure, firewalls and data encryption can be utilized. Work processes such 
as password confidentiality, premises and other offline attributes can affect any online security processes. 

Security js crudal for this project due to the sensitive nature of the data on the site. Protocol transmission 
will be encrypted via the 128-bit SSL protocol thereby protecting all data in transfer between the browser 
and the server. Access to the server will be restricted via a username and password; this is a compromise 
between security needs and ease-of-use. Data on the system will all be stored within a secure database 
which will be accessible only via a limited number of accounts. These accounts will be utilized by the 
application and any manual administration only. 



Compatibility is the conformance of the system to existing and upcoming industry standards such as 
HTML, XML, SQL, etc These standard protocols and data formats allow the system to communicate with 
other systems at the present time and in the future. This also includes any client software such as 
browsers that access the system. 

The site will not have any external stubs for other applications to access. All data will be stored in a 
standard RDBMS and all data calls will be written in standard SQL All custom user interface elements will 
be written to produce HTML and possibly DHTML. 

All HTML will conform to the W3Cs HTML 4.01 specification as defined on their website www.w3c.orQ . All 
client-side JavaScript will conform to Netscape's JavaScript 1.3 specification as defined on their website 
www.netscape.com . 

No allowance will be made for any browser-specific inconsistencies with the specifications listed above. 
Any issues that result from browser inconsistencies are not covered. • 



Compatibility 



Grounds well 



Page 4 of S 



Integration 

Integration is defined as the relationship between this project's application(s) and any other applications 
Other applications could include legacy mainframe systems, transaction-based systems, ERP systems 
CRM systems, fulfillment systems or custom applications. ' 

No integration with any existing systems is required. All existing information, applications and assets will 
be transferred to the new site thereby eliminating the need for integration with the existing site. 

Back-up & Recovery 

Back-up & Recovery is the processes that are used to archive the software portion of the system for 
restoration and historical uses. Normally a backup device is used to store all data and the software itself 
Any information such as log files that are not needed for operations but are necessary for historical data 
analysis are normally moved to an offline storage site. 

The site will have a full daily backup of all software and data; this includes both the code itself and the 
r^T^?* M badf !S s wi " be available for a Ml restoration of the site within 4 hours. All log files will 
be stored in on- or offline storage for at least 3 months before permanent removal. The client will always 
have the option of archiving the data themselves at their own cost. 

All backup and recovery responsibilities for each system rest on the administrator of said system. 
Therefore if the client administers a system they are responsible for the backup and recovery. 

Disaster Recovery 

Disaster recovery is the ability to restore the site in the event that the entire system infrastructure 
including hardware and facilities is temporarily or permanently disabled. 

A full disaster recovery plan will be made available to the client by the hosting provider. This will include 
JiSff ? Cat,0n I° r h "!£ n ? wlth «"H»hI* services as the primary location and a transmit plan 
li provided *' ^ frame W '" required for a M transfer will also 



Supporting Documents 

Subject Document Title Location 

Requirements Business Process Flow Portal 
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